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DETAILED ACTION 

1 . This action is in response to the annendment filed 1/18/2005. 

2. As per applicant's request, claims 7, 24, 27, and 30 have been cancelled, claims 
1, 8, 12-15, 17-26, 29, 31, and 32 have been amended and claims 36-54 have been 
added. Claims 1, 3-6, 8, 12-23, 25, 26,28, 29, and 31-54 are pending in the application. 

Specification 

3. The specification is objected to because: The auxiliary verb "may" used throughout 
the specification is not specific and clear enough concerning the invention's function. It 
is unclear whether the invention performs the described functionality or not. It should be 
stated in a more definitive manner. *Note: The applicant refuses to correct the objection 
to the specification because the portion of the cited MPEP is only directed to the 
abstract. However, the examiner notes that the entire specification is objected in the 
previous action ("The specification is objected to... throughout the specification") and the 
MPEP portion cited is for reference only, specifically for the abstract which is a part of 
the specification. Therefore, the objection to the specification is maintained. 

Claim Rejections - 35 USC §112 

4. The rejection to claims 1 , 3-8, and 12-35 has been withdrawn due to the 
amendment to the claims. However, see "Response to Arguments" below for the 
interpretation. 
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Claim Rejections - 35 USC § 102 

5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
states. 

6. Claims 1, 3-6, 8,12-23, 25, 26,28, 29, 31-34, and 36-54 are rejected under 35 
U.S.C. 102(b) as being anticipated by MathWorks ("Stateflow for State Diagram 
Modeling User's Guide," version 4, 1997-2001). 

Per claim 1: 
MathWorks discloses: 

-receiving the state diagram information, wherein the state diagram information 
represents the state diagram and specifies a plurality of states ("Stateflow is used 
together with Simulink ...Simulink supports development ...in a graphical block diagram 
environment," page 1-3; "A Stateflow diagram is a graphical representation of a finite 
state machine where states and transitions form the basic building blocks of the 
system... Stateflow provides a block that you include in a Simulink model," page 2-2) 
-automatically generating the graphical program in response to the state 
diagram information ("creating a Simulink model with a Stateflow block," page 1-6) 
-wherein said automatically generating comprises automatically generating graphical 
source code corresponding to the plurality of states, wherein the graphical source code 
comprises a plurality of interconnected nodes which visually indicate functionality of the 
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graphical program ("A Simulink model can consist of combinations of Simulink blocks, 
toolbox blocks, and Stateflow blocks," page 2-4; see the figure in page 2-7) 
-wherein the graphical program is executable by a computer (The Simulink model and 
Stateflow machine work seamlessly together. Running a simulation automatically 
executes both the Simulink and Stateflow portions of the model," page 2-4) 
-said automatically generating the graphical program creates the graphical program 
without any user input specifying the graphical program during said creating (see the 
figure in section Creating a Simulink Model, page 1-6) as claimed. 

Per claims 3-6: 

A state diagram is used to describe the behavior of a system and each diagram usually 
represents objects of an individual class and identifies the different states of its objects 
through the system. As an algorithm is any sequence of operations for performing a 
specific task, the state diagram can represent any desired operations, any other non- 
software system so that each state of operation can be specified, conceptualized, 
visualized, and constructed in the diagram. Thus, a state diagram can represent 
desired operation of a software program, a hardware device, algorithm, and test 
sequence. Therefore, accordingly, MathWorks anticipate these claims. 

Per claim 8; 

The rejection of claim 1 is incorporated, and further, MathWorks teaches: 
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- automatically generating a block diagram including the graphical source code 
corresponding to the specified plurality of states ("creating a Simulink model with a 
Stateflow block," page 1-6) as claimed. 

Per claim 12: 

The rejection of claim 1 is incorporated, and further, MathWorks teaches: 

- for at least one state of the plurality of states, the state diagram information specifies 
program code associated with the state; wherein the automatically generated graphical 
source code includes the specified program code ("creating a Simulink model with a 
Stateflow block," page 1-6) as claimed. 

Per claim 13: 

The rejection of claim 1 is incorporated, and further, MathWorks teaches: 

- for at least one state, the state diagram information specifies program code associated 
with the state; wherein the automatically generated graphical source code is operable to 
invoke the specified source code (see the figure in section Creating a Simulink Model, 
page 1-6) as claimed. 

Per claim 14: 

The rejection of claim 1 is incorporated, and further, MathWorks teaches: 

- the state diagram information further specifies one or more state transitions, wherein 
each state transition specifies a transition from a first state to a second state; wherein 
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said automatically generating further comprises automatically generating graphical 
source code corresponding to the specified state transitions (See the section Creating a 
Stateflow diagram, 4 Create transitions, page 1-10 and 1-11) as claimed. 
Per claim 15: 

The rejection of claim 14 is incorporated, and further, MathWorks teaches: 
-the automatically generated graphical source code includes placeholder graphical 
source code for each state transition (see the figure in section Creating a Simulink 
Model; "You can either start with the default empty model or copy the untitled Stateflow 
block into any S, page 1-6) as claimed. 

Per claim 16: 

The rejection of claim 15 is incorporated, and further, MathWorks teaches: 
-for one or more state transitions, a user manually entering graphical source code 
specifying a Boolean condition associated with the state transition (section Transitions 
in page 7-14-7-26) as claimed. 

Per claim 17: 

The rejection of claim 14 is incorporated, and further, MathWorks teaches: 
-wherein the state diagram information specifies at least two state transitions from a 
particular state; wherein the state diagram information also specifies a priority ordering 
for the at least two state transitions; wherein said automatically generating comprises 
automatically generating graphical source code such that, during execution of the 
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graphical program, Boolean conditions associated with the at least two state transitions 
are evaluated in the specified priority ordering (section Transitions in page 7-14-7-26) 
as claimed. 

Per claim 18: 

The rejection of claim 1 is incorporated, and further, MathWorks teaches: 

- the state diagram information further specifies an initially active state; wherein said 
automatically generating comprises automatically generating graphical source code 
such that the graphical program begins execution in the initially active state (see section 
Creating and Changing States, page 3-15-3-21 ) as claimed. 

Per claim 19: 

The rejection of claim 1 is incorporated, and further, MathWorks teaches: 

- the state diagram information further specifies one or more stop states; wherein said 
automatically generating comprises automatically generating graphical source code 
such that if during execution of the graphical program one of the stop states becomes 
active, then the graphical program is caused to stop execution (see section Creating 
and Changing States, page 3-15-3-21) as claimed. 

Per claim 20: 

The rejection of claim 1 is incorporated, and further, MathWorks teaches: 

- receiving information specifying a change to the state diagram information; 
automatically updating the graphical program to reflect the specified change (see 
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section Creating and Changing States, page 3-15-3-21; Inputting Events from Simulink, 
page 5-16) as claimed. 
Per claim 21: 

The rejection of claim 1 is incorporated, and further, MathWorks teaches: 
-calling an application programming interface (API) enabling the programmatic 
generation of a graphical program (see API properties and methods in Appendices A-C) 
as claimed. 
Per claim 22: 

The rejection of claim 1 is incorporated, and further, MathWorks teaches: 
-automatically requesting a server program to generate the graphical program (see API 
properties and methods in Appendices A-C) as claimed. 

Per claims 23 and 24, they are another method versions of claims 1 and 7, 
respectively, and are rejected for the same reasons set forth in connection with the 
rejection of claims 1 and 7 above. 

Per claim 25, this claim is another version of the claimed method discussed in 
claim 20, wherein all claim limitations also have been addressed and/or covered in cited 
areas as set forth the above. 

Per claims 26-28, they are the system versions of claims 1 , 7, and 8, 
respectively, and are rejected for the same reasons set forth in connection with the 
rejection of claims 1, 7, and 8 above. 
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Per claims 29-31 , they are the memory medium versions of claims 1 , 7, and 8, 
respectively, and are rejected for the same reasons set forth in connection with the 
rejection of claims 1 , 7, and 8 above. 

Per claims 32-34, these claims are another versions of the claimed method 
discussed in claims 1,16, and 18, wherein all claim limitations also have been 
addressed and/or covered in cited areas as set forth the above. 
Per claim 36: 
MathWorks discloses: 

-receiving the state diagram information, wherein the state diagram information 
represents the state diagram and specifies a plurality of states ("Stateflow is used 
together with Simulink ...Simulink supports development ...in a graphical block diagram 
environment," page 1-3; "A Stateflow diagram is a graphical representation of a finite 
state machine where states and transitions form the basic building blocks of the 
system... Stateflow provides a block that you include in a Simulink model," page 2-2) 
-automatically generating the graphical program in response to the state 
diagram information ("creating a Simulink model with a Stateflow block," page 1-6) 
-wherein said automatically generating comprises automatically generating graphical 
source code corresponding to the plurality of states, wherein the graphical source code 
comprises a plurality of interconnected nodes which visually indicate functionality of the 
graphical program ("A Simulink model can consist of combinations of Simulink blocks, 
toolbox blocks, and Stateflow blocks," page 2-4; see the figure in page 2-7) 
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-wherein the graphical progrann is executable by a computer (The Simulink model and 
Stateflow machine work seamlessly together. Running a simulation automatically 
executes both the Simulink and Stateflow portions of the model," page 2-4) 
-said automatically generating the graphical program creates the graphical program 
without any user input selecting the nodes or establishing connections between the 
nodes (see the figure in section Creating a Simulink Model, page 1-6) as claimed. 

Per claims 37 and 38, they are the memory medium versions of claims 36 
respectively, and are rejected for the same reasons set forth in connection with the 
rejection of claim 36 above. 

Per claims 39-48, they are the memory medium versions of claims 8-20 
respectively, and are rejected for the same reasons set forth in connection with the 
rejection of claims 8-20 above. 

Per claim 49: 
MathWorks discloses: 

The rejection of claim 37 is incorporated, and further, MathWorks teaches: 
-the state diagram information comprises an executable program (The Simulink model 
and Stateflow machine work seamlessly together. Running a simulation automatically 
executes both the Simulink and Stateflow portions of the model," page 2-4) as claimed. 
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Per claim 50, this claim is the method version of the claimed medium discussed 
in claim 37, wherein all claim limitations also have been addressed and/or covered in 
cited areas as set forth the above. 

Per claims 51 and 52, these claims are another version of the claimed method 
discussed in claim 37 and 38, wherein all claim limitations also have been addressed 
and/or covered in cited areas as set forth the above. 

Per claims 53 and 54, these claims are another version of the claimed method 
discussed in claim 37 and 38, wherein all claim limitations also have been addressed 
and/or covered in cited areas as set forth the above. 

Claim Rejections - 35 (JSC § 103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

8. Claim 35 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
MathWorks ("Stateflowfor State Diagram Modeling User's Guide," version 4, 1997- 
2001 ) in view of Kodosky et al. (US 5,732,277). 

Per claim 35, MathWorks does not explicitly teach that the placeholder graphical source 
code for each state comprises a case in a graphical case structure. However, Kodosky 
et al. disclose that the placeholder graphical source code for each state comprises a 
case in a graphical case structure (col 20, lines 30-49;col 1 1 , lines 43-60, col 1 1 , lines 
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44-60) so that it is easy for a user to cycle through the alternatives of each case. 
Therefore, It would have been obvious to one having ordinary skill in the art at the time 
of the invention was made to incorporate the teaching of Kodosky et al. to the system of 
MathWorks. The modification would have been obvious because one having ordinary 
skill in the art would have been motivated to include a case structure so that a menu list 
of alternatives on the screen for a user to choose from is available. 

Response to Amendment 

9. In claim 23 of the amendment, the deleted word, "automatically in line 1 1 
shown by strike-through was not presented in the original version. The new corrected 
amendment is required upon response to this office action. 

The new abstract (page 3) must be submitted on a separate sheet (37 CFR 

1.72). 

Response to Arguments 

10. Applicant's arguments filed 1/18/2005 have been fully considered but they are 
not persuasive. 

Regarding 112 Rejections, the applicant argues that: 

The Background further states that: users may greatly benefit from the automatic generation of a 
graphical program skeleton that provides a framework for the various states and transitions... and 
relationships among these... of the state diagram (page 18)... the application clearly indicates that 
...generation of a complete graphical program, and/or generation of a portion of a graphical program, i.e. 
a framework to which other graphical source code may be added, e.g., by the user (page 18). 
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In response, the independent claims do not explicitly recite the automatically 
generated graphical program as a skeleton, placeholder, containers, or stub program 
(which is "well-known," Remark, page 18) that provides a "framework to which other 
graphical source code may be added by the user ...[or] includes an overall program 
structure or framework... where the stubbed out functions are generally intended to be 
fleshed out with source code later ...by the user (page 18)." Also, as the applicant 
admits, "automatically generating a graphical program based on a state diagram 
requires "little or no user input (Remark, page 18; see also specification, page 29, 
"graphical program may be automatically generated with little or no user input received 
during this generating. In one embodiment, the graphical program is automatically 
generated with no user input required. In another embodiment, the user may be 
prompted for certain decisions during programmatic generation"), it is clear that the 
scope of the term "automatically" includes the manual user input. The applicant 
replaced the term "programmatically" with "automatically." However, the applicant 
continues to use these two terms interchangeably and clearly indicates that 
"automatically" means "programmatically" "in other words (Remark, page 19)." The 
applicant's claim, "the programmatic generation of the graphical program is in contrast 
with the manual creation of the graphical program (Remark, page 19)" is contradictory 
to the statement of "with little or no user input required." Therefore, the examiner 
interprets "automatically generating" refer to an action being performed by either a 
program or the user as the independent claims do not define what the automatically 
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generated graphical progrann is. If applicant means anything more, this must be 
brought out in the claims to further clarify the invention. 

Per claim 1: 

The applicant states that: 

The cited portions of the Stateflow manual clearly describe manual inclusion of a Stateflow block in a 
Simullink model diagram. ..the Stateflow block is used as an element in the Simulink model, and is not 
used as a basis for automatically or automatically generating graphical program source code. Nowhere 
does MathWorks teach or describe automatically or automatically generating graphical program source 
code based on received state diagram infonnation (page 27). 

In response, "automatically generating" is interpreted to refer to an action being 

performed by either a program or the user and MathWork clearly recites that a Stateflow 
diagram is a graphical representation of a finite state machine where states and 
transitions form the basic building blocks of the system... Stateflow provides a block that 
you include in a Simulink model ( page 2-2)" in a graphical block diagram environment . 
Furtermore, MathWorks states "Stateflow Coder generates... code based on the 
Stateflow machine (page 1-4)." Therefore, MathWorks discloses automatic generation 
of graphical program source code based on state diagram information. If applicant 
means anything more, this must be brought out in the claims to further clarify the 
invention. Accordingly, in view of the broadest reasonable interpretation, MathWorks 
discloses the limitations in claim 1 ; therefore, the rejection of claim 1 is considered 
proper and maintained. 
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Per claims 23, 25, 26, and 29: 

The applicant states that MathWorks does not disclose the limitations of claims 23, 25, 
26, and 29, for the reasons set forth in connection with claim 1 . As shown above, the 
rejection of claim 1 by MathWorks was maintained, and accordingly, the rejections of 
claims 23, 25, 26, and 29 are also maintained. 

Per claim 32: 

In response to applicant's argument that the reference fails to show certain 
features of applicant's invention, it is noted that the features upon which applicant relies 
(i.e., the second one or more nodes correspond to the framework embodiments... in . 
which basic structure of the graphical program is programmatically or automatically 
generated, but source code for these nodes is provided or configured by the user, page 
27) are not recited in the rejected claim(s). Although the claims are interpreted in light 
of the specification, limitations from the specification are not read into the claims. See 
In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). As such, the 
claims are read with the broadest reasonable interpretation in mind (Note MPEP 21 1 1). 

Per claim 35: 

The applicant states that: 

Nothing disclosed In either of the cited references provides or suggests a motivation to combine the 
references. Thus Applicant submits that the attempted combination of MathWorks and Kodosky is 
improper. Additionally, Applicant submits that even were MathWorks and Kodosky properly combinable, 
which Applicant argues they are not, the resulting combination would still not teach Applicant's invention 
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as represented in claim 35. For example, neither reference discloses or even hints at the programmatic 
or automatic generation of graphical program sourced code based on received state diagram infomnation, 
and more specifically, neither reference teaches or describes: wherein a second one or more nodes are 
user-configurable. ..comprises a case in a graphical case structure (page 30)." 

In response, the applicant fails to sliow that the reasons to combine and 
motivations concerning the rejection of claim 35 are improper. Furthermore, it is noted 
that Kodosky uses a case structure, which is a well-known programmatic structure in 
the art of programming (see "Case (Conditional) Selection Structure," col 20, lines 30- 
49;col 1 1 , lines 43-60, col 11, lines 44-60). Kodosk/s reference is provided as one of 
references that teaches the known feature. MathWorks discloses automatic generation 
of graphical program source code based on received state diagram information as 
addressed above and Kodosky teaches a case structure. Thus, all the graphical 
programming aspects described in MathWorks do fulfill the features brought out in 
applicant's claims, given that the programming aspect of Kodosky is combined into 
them, for which the motivation is as given above. If applicant means anything more, this 
must be brought out in the claims to further clarify the invention. 

Conclusion 

1 1 . THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
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TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

1 2. Any inquiry concerning this communication or eariier communications from the 
examiner should be directed to Insun Kang whose telephone number is 571-272-3724. 
The examiner can normally be reached on M-F 7:30-4 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on 571-272-3719. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact^the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 



I. Kang 

Examiner 

4/26/2005 
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